Geogame for mobile device

ABSTRACT

In a geographic location based game (geogame), players (actual persons) utilize mobile communications devices to play a game in which players catch virtual “good” objects and/or avoid virtual “bad” objects. Virtual objects can be stationary, move in accordance with deterministic pattern, move in accordance with non-predetermined patterns, and/or move randomly. Players acquire points by capturing a virtual good object. Players capture virtual good objects by physically moving to the geographic location of a virtual object. If a player comes in contact with a “bad” virtual object, the player loses points. Captured virtual objects can be used to attack other players and/or virtual objects.

TECHNICAL FIELD

The technical field generally relates to a game based on the geographiclocation (geolocation-based game or geogame) of the players, and morespecifically to geolocation-based gaming using a scalable tiered geocastprotocol, and even more specifically to a geolocation-based game whereinaccording to the rules of the geogame, players capture and/or avoidvirtual objects.

BACKGROUND

Video games are extremely popular. As a result of advances intechnology, physical activity of a player can be incorporated into avideo game (e.g., Nintendo's® Wii™) Players of video games involvingphysical activity and/or movement are typically limited to playing thegames within restricted environments. For example, players of manygaming systems interact with the gaming system via wired and/or wirelesscontrollers. The controllers have a limited range, thus, limitingphysical video games to indoor use within a limited range from a gamingconsole and/or home entertainment system. Even wireless controllerslimit game play to a small portion of a room by ultra short-rangesignals used to allow a player to see the video monitor. Often gameconsoles must be positioned on a stable, flat surface, and require 110volt connections to a power supply. These characteristics leave gamingconsoles with little to no portability.

Multiplayer versions of video games involving physical movementtypically allow multiple players to compete against one another. Playersmay be located within one physical area, with simultaneous access to onegaming console, or may be located at various physical areas and link upover a network such as the Internet. Despite the physical distanceseparating them, players engaged in a multiplayer game from differentphysical locations still have the above described limited movementrestriction imposed upon them. Further, these games typically rely onthe constant presence of wireless and/or wireline network connectivity.If access to the network is interrupted, for even very short periods oftime, the multiplayer gaming experience can be deteriorated or lostaltogether. Thus, it is sometimes not possible to enjoy multiplayergaming involving physical movement at all, for example in a remotegeographic area with limited or no network service available.

SUMMARY

Various types of geographic location based games (geogames) andmechanisms for implementing geogames are described herein. Alsodescribed is a geographic broadcast (“geocast”) protocol forimplementing geogames. In an exemplary geogame, players (actual persons)utilize mobile communications devices (also referred to as wirelessterminals or WTs) to play a game in which players move in order to catch(capture) virtual “good” objects and/or avoid virtual “bad” objects. Invarious embodiments, virtual objects can be stationary, move inaccordance with deterministic pattern, move randomly, or any combinationthereof. For example, in one example embodiment, virtual good objectsremain stationary, and a player, or players, acquires points bycapturing virtual good objects. A player captures a virtual good objectby occupying the geographic location of the virtual object. In anotherexample embodiment, virtual good objects move in deterministic patterns,and a player, or players, acquires points by capturing virtual goodobjects. In yet another example embodiment, virtual good objects moverandomly, and a player, or players, acquires points by capturing avirtual object. In another example, embodiment, virtual objects moveaway from a player as a player gets close to the virtual object. Inanother example embodiment, if a player comes in contact (occupies thegeographic location) of a “bad” virtual object, the player loses points.In various example embodiments, bad virtual objects can remainstationary, move in accordance with deterministic patterns, moverandomly, and/or chase players. In yet another example embodiment,captured virtual objects can be used to attack other players and/orvirtual objects.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example mobile ad hoc network in which geogamingmay be implemented.

FIG. 2 illustrates example communications in an ad hoc network in whichgeogaming can be implemented via a WiFi access point.

FIG. 3 illustrates an example mobile ad hoc network in which geogamingcan be implemented utilizing tiered geocasting and forwarding zones.

FIG. 4, comprising FIG. 4A-FIG. 4E depict example geocast regions orboundaries.

FIG. 5 depicts a geogame player located in a geogame play region asrendered on a wireless terminal.

FIG. 6 depicts “good” virtual objects.

FIG. 7 depicts “bad” virtual objects.

FIG. 8 depicts good virtual objects 50 and bad virtual objects 52located in a player's game play region.

FIG. 9 depicts multiple geogame players along with good virtual objectsand bad virtual objects, as rendered on a wireless terminal.

FIG. 10 depicts an example location and boundary of a virtual object.

FIG. 11 depicts renderings of multiple players and multiple virtualobjects in different, distinct, physical locations.

FIG. 12 depicts a good virtual object being converted to an attackvirtual object.

FIG. 13 depicts a list from which a player can select a destination,termination, boundary, region, or the like.

FIG. 14 depicts a position of a player on a map displayed on a wirelesscommunications device.

FIG. 15 depicts an example rendering of a start time of a geogame.

FIG. 16 is an example depiction of multiple players having joined thegeogame.

FIG. 17 is a flow diagram of an example process for playing a geogame.

FIG. 18 is an illustration of an example relationship between eventhistory and state values in a geogame.

FIG. 19 is a depiction of an example a global event history.

FIG. 20 is another flow diagram of an example process for playing ageogame.

FIG. 21 is a block diagram of an example communications deviceconfigured to facilitate geogaming.

FIG. 22 depicts an overall block diagram of an exemplary packet-basedmobile cellular network environment, such as a GPRS network, withinwhich geogaming can be implemented.

FIG. 23 illustrates an architecture of a typical GPRS network withinwhich geogaming can be implemented.

FIG. 24 illustrates an exemplary block diagram view of a GSM/GPRS/IPmultimedia network architecture within which geogaming can beimplemented.

FIG. 25 illustrates a PLMN block diagram view of an exemplaryarchitecture in which the geogaming may be incorporated.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Various embodiments of geographic location based gaming, referred to asgeogaming, and implementation mechanisms for geogaming are describedherein. The described embodiments are merely examples that may beembodied in various and alternative forms, and combinations thereof. Asused herein, for example, “exemplary,” and similar terms, referexpansively to embodiments that serve as an illustration, specimen,model, or pattern. The figures are not necessarily to scale and somefeatures may be exaggerated or minimized, such as to show details ofparticular components. In some instances, well-known components,systems, materials, or methods have not been described in detail inorder to avoid obscuring the instant disclosure. Therefore, specificstructural and functional details disclosed herein are not to beinterpreted as limiting, but rather as a basis for the claims and as arepresentative basis for teaching one skilled in the art how to employthe teachings instant application in various ways.

While the description includes a general context of computer-executableinstructions, geogaming also can be implemented in combination withother program modules and/or as a combination of hardware and software.The term “application,” or variants thereof, is used expansively hereinto include routines, program modules, programs, components, datastructures, algorithms, and the like. Applications can be implemented onvarious system configurations, including single-processor ormultiprocessor systems, minicomputers, mainframe computers, personalcomputers, hand-held computing devices, microprocessor-based,programmable consumer electronics, combinations thereof, or the like.

In an example embodiment, geogaming is implemented via a scalable,wireless, geographic broadcast (“geocast”) protocol. Geogaming via ageocast protocol enables multiplayer gaming between mobile communicationdevices, such as wireless terminals (WTs) without relying on traditionalnetwork elements. No gaming console is required, thus eliminating thevenue restrictions imposed by wired controllers and/or wirelesscontrollers with limited ranges. Geogames can be played in wide openspaces, either indoors or outdoors. Geogaming can be fully distributedover an ad hoc network of mobile communications devices, eliminating theneed for traditional mobile communications infrastructure and centralservers. Because no network infrastructure is required to play,geogaming can take place in remote areas with little or no networkaccess; for example in the middle of the woods. The scalable nature ofthe geocast protocol enables geogames to function equally well in bothremote areas and crowded areas containing both geogame players and otherusers of mobile communications devices. Because multiplayer geogames donot require constant communication with a central server, game play canbe more physically active and geographically wide ranging. Geogamingusing tiered geocasting enables geogame players to participate inmultiplayer gaming spanning great distances. For example, players onseparate continents may participate in a single multiplayer geogame.

In an example embodiment, WTs taking part in a geogame are programmedwith a geogaming application, which uses geolocation informationobtained from a locating system, such as, for example, a globalpositioning system (GPS), or the like.

The geogaming application of each WT in the game controls a position ofa simulated or virtual player based on location data received from thelocation system. In some embodiments, the geogaming application in theWT uses movement data from an inertial unit, or the like, of the WT tocontrol a posture and/or movement of a virtual player, and/or to render(e.g., display) a posture and/or movement of an actual player, todetermine and control locations of virtual objects, and/or to renderlocations of virtual objects.

The scalable tiered geocast communication protocol is programmed intoeach WT taking part in the geogame, and any WT that operates to relaycommunications to or from the WTs taking part in the geogame. The WTstaking part in the geogame share changed game conditions, such as WTgeolocation, between them via geocast data packets transmitted over oneor both of a first tier, short-range, network, and a second tier,long-range, network according to transmission heuristics of the tieredgeocast protocol.

The herein described geogaming architecture can be used to facilitate awide variety of geogames. In one example, a geogame, which is describedin U.S. patent application Ser. No. 12/835,385, entitled “Location BasedMobile Gaming Application And Method For Implementing The Same Using AScalable Tiered Geocast Protocol,” filed Jul. 13, 2010, which isincorporated by reference herein in its entirety, involves playersvirtually hitting, or virtually catching and throwing, back and forth agame object, such as a virtual ball or flying disc. Movements of thevirtual game object are also shared between WTs in geocast data packetstransmitted according to the tiered geocast protocol. In someembodiments, other game information, such as location and size ofpredefined playing areas, and scoring during the game, are propagated ingeocast data packets according to the tiered geocast protocol.

Another example geogame, which is described in U.S. patent applicationSer. No. 12/644,293, entitled “Augmented Reality Gaming Via GeographicMessaging,” filed Dec. 22, 2009, which is incorporated by referenceherein in its entirety, involves a virtual mortar shell or a virtualnuclear strike in a military simulation game. Yet another examplegeogame, also described in U.S. patent application Ser. No. 12/644,293,involves a virtual unmanned aerial vehicle (UAV), which can providereconnaissance information about the location of other players of ageogame.

In another example geogame, which is described in U.S. patentapplication Ser. No. 12/914,811, entitled “Geogame For Mobile Device,”filed Oct. 28, 2010, which is incorporated by reference herein in itsentirety, players, utilizing wireless devices, are required tocontinuously physically move within a defined boundary throughout thegeogame. The wireless devices, with the aid of a location system, suchas GPS, track the movements of the players. As players move, virtualtails are generated behind each player, and their locations aredetermined and geocast, via a wireless geographic broadcast protocol, toall players of the geogame. Each player observes all players movementsand tail locations on his/her wireless device. If a player stops moving,the player is expelled from the game. If a player exits the confines ofthe boundary, the player is expelled from the game. If a player crossesa virtual tail, the player is expelled from the game. If two virtualtails cross, both players are expelled from the game. The last playerremaining is the winner.

In another example geogame, described herein, distributed virtualobjects are controlled by using a scalable wireless geocast protocol topropagate timely messaging. Within this messaging, several distributedalgorithms operate to distribute virtual object state updates. Inoperation, the geogame comprises multiple levels, with each levelpresenting different types of challenges and different virtual objectbehaviors. On one level, a set of “good” virtual objects fly randomlyaround the landscape, while the user must run/move so that the user'sdevice detects its location to lie within the boundary of a virtualobject, thereby ‘catching’ it and obtaining points. As one playercatches a virtual object, that virtual object is no longer available forother players to catch. Thus, state changes are propagated to allplayers in the area (via geocast messaging). Another example level adds“bad” virtual objects. According to the rules of game play, players mustmove so that their location does not lie within the bad virtual objectboundaries or else they lose points for such time. Another level addsthe behavior of a good virtual object “flying away” from players, makingit harder for players to catch them. Since this requires them to reactto the players' positions, it requires distribution of state changes aswell. Another level adds bad virtual object that chase players. Anotherlevel gives players the ability to command captured virtual object as“attack objects”. Timestamps, voting protocols, and multiphasecommitment protocols are used to implement distributed virtual objectstate changes.

In an example embodiment, each WT taking part in the geogame isprogrammed with the scalable tiered geocast communication protocol. Oneexample of a type of scalable protocol is the mobile ad hoc networkgeocast protocol. Using the tiered geocast protocol, geogaming can beoccasioned in all types of network scenarios, including those in whichrelevant areas are densely populated with participating WTs, those inwhich areas are sparsely populated, and even in areas long-rangeinfrastructure such as cell towers, WIFI hotspot or other Internetrouter are not reachable by the WTs taking part in the game.

Geocast protocols differ from a traditional Internet protocol (IP) suchas the uniform datagram protocol (UDP) in that messages are addressed toa destination geocast region instead of an IP address, such as an UDPaddress. Utilizing the geocast protocol, WTs in a target area do notneed to register to a group address, as required of some otherprotocols. In some example embodiments, each geocast data packet isassigned, at origination, a globally unique packet serial number. Theunique packet serial number is read by participating devices accordingto the protocol to, for example, determine whether a particular datapacket is being received for a first time or has been received before.The packet serial number and all other packet information may bepositioned in a header or body of the data packet.

The geogaming application is in some embodiments configured to storepre-set or previously identified geocast destination, locations, region,or the like, and allow the initiating player to select appropriately forgeocasting.

Geocast data packets are transmitted according to heuristics of a tieredgeocast protocol, which is described in more detail herein, to adestination geocast region for reception by all devices located in theregion that are programmed with the geocast protocol, i.e.,participating devices.

Although basic geocasting over only a single network (e.g., long-rangenetwork) enables communications in some situations where traditionalnetworking is impractical or inadequate, it is in some embodimentspreferable to selectively geocast over one or more of two or morenetworks (i.e., tiers) versus the flat configuration of a singlenetwork. The tiered geocast protocol of the present disclosure improveson single-network geocasting by providing the heuristics, or decisionrules, for selectively propagating geocast data packets within arelatively short-range, peer-to-peer network, and bridging packets ontoa long-range network for long-distance transport depending on variouscircumstances. Each participating WT and other nodes (e.g., WIFI accesspoint or other router) have forwarding rules, including geographicalparameters, and a look-up table for use in implementing the rules.

In one embodiment, the geocast system is configured such that atransmitting WT receives a confirmation that a geocast data packet wastransmitted successfully. For example, it is contemplated that at leastone of the WTs in a geocasting destination region, even if not a WTactively participating in the game, could return geocast a confirmationdata packet indicating that the packet was received by a WT in theregion. In one contemplated embodiment, although the protocol is basedon a geographical address and not a device-specific address, adevice-specific address of a target WT participating in the game isincluded in a geocast and the target WT initiates inclusion in a returngeocast data packet of a confirmation of receipt message to theoriginating WT.

In addition, in some embodiments, a geocast data packet includes one ormore fields, such as in a header or body of the packet, in whichinformation related to a path taken by a packet is recorded. Forexample, a receiving node (e.g., WT or Internet router) receiving ageocast can retrieve data from the geocast header to identify an orderedlist of the nodes whose transmissions led to the receiving nodereceiving it. In this way, path discovery is integrated into thetransmission process. Any node can also use this information to send asource-routed unicast back to any node along the path, which is termedreverse-path forwarding (RPF).

Although a two-tiered communication system, including a firstshort-range peer-to-peer network and a long-range network, is primarilydescribed herein, the geogaming application of the present disclosuremay be implemented in connection with a protocol and communicationsystem using other types of networks as well as or instead of thosedescribed herein, and in connection with more than two network tiers.

Propagations over the short-range network are made between devicesprogrammed with the scalable tiered geocast protocol, whereby adjacentdevices are within range of each other, such as radio range (e.g., 100meters). The WTs and tiered geocast protocol are configured to transmitgeocast data packets over one or more short-range networks, includingexisting wireless local area networks (WLANs), such an IEEE 802.11network. As an example, when a first gaming WT is about 900 meters froman edge of a geocasting region including a second gaming WT, a geocastdata packet from the first device would be broadcasted and participatingintermediate devices would receive and retransmit the geocast datapacket until it reached the geocast region, without need fortransmission over an Internet router or other base station. In thisexample, depending on the location of a retransmitting device, thegeocast data packet can be broadcast to the geocast region in one or twohops.

Geogaming is particularly suited to highly mobile devices withoutrequiring connection to an infrastructure-based communications network.A mobile ad hoc network is an example of such a set of devices. Mobilead hoc networks extend the reach of data networking into areas andscenarios in which infrastructure-based networking is impossible orimpractical. For example, mobile ad hoc networks can allow firstresponders to use networked messaging and information applications in azone where the network infrastructure has been destroyed by a disaster.Mobile ad hoc networks can provide military units operating inbattlefield situations lacking infrastructure the same types of benefitsas infrastructure-based networks. Mobile ad hoc networks can allownetworking among low resource nodes, such as man-worn devices powered bylightweight wearable batteries, by allowing units to relay each other'sshort-range transmissions, instead of each unit transmitting long rangedirectly to the destination.

To better understand geogaming and applications thereof, a descriptionof mobile ad hoc networks is provided. In is to be understood however,that applications of geogaming are not limited to mobile ad hocnetworks. Rather, geogaming is applicable to any appropriate device orgroup of devices.

A mobile ad hoc network comprises communications devices (also referredto as nodes) that communicate with each other via geographicalbroadcasting, referred to as geocasting. Geocasting is described in U.S.Pat. No. 7,525,933, entitled “System And Method For Mobile Ad HocNetwork,” filed Nov. 30, 2005, issued Apr. 28, 2009, and is incorporatedby reference herein in its entirety. Geocasting uses a protocol in whichan IP address is replaced with a geographic address. Thus, each geocastmessage comprises an indication of a location of a geographic region ofintended reception of the geocast message. Generally, a packet is sentto every communications device located within a specific geographicregion. The packet can contain an indication of the location of thesender, an indication of the geographic region, a payload, or acombination thereof, or the like. The communications devices in thegeographic region, and any other communications devices that cancommunicate with them, are referred to, collectively, as a mobile ad hocnetwork. No registration is required to become a member of the mobile adhoc network. Any communications device in the mobile ad hoc network cansend a message to any or every communications device in the mobile adhoc network. As communications devices move within communications rangeof any member of the mobile ad hoc network, they can become members ofthe mobile ad hoc network without requiring registration. Thecommunications devices of the ad hoc network of communications devicescommunicate with each other. The ad hoc network of communicationsdevices does not require base station terminals to controlcommunications between the mobile devices. In example embodiments, basestations or routers may be used to relay messages between differentmobile ad hoc networks, or to use other network transports such as othertraditional internet protocol networks, such as the internet, to bridgemessages between mobile ad hoc networks. Each communications device iscapable of receiving and/or transmitting data packets to and/or fromother communications devices in the mobile ad hoc network.

In an example embodiment, a communications device transfers packets toother communications devices according to heuristic decision rules thatdetermine whether a receiving device will re-transmit a received packet.These rules effectively guide packets to their destinations and controlcommunication traffic within the ad hoc network. The decision rulesachieve this control by using statistics obtained and recorded by acommunications device as it receives packets transmitted withinreception range within its environment. This distributed packet transfermechanism results in packets “flowing” to and throughout the geocastregion specified in each packet. The communications devices in thegeocast region receive and process each distinct packet, typicallyrendering the content to the user via a user interface of acommunications device. Two packets are distinct if they contain distinctgeocast identifiers. However, a re-transmitted copy of a packetgenerally will contain the same geocast identifier as the originalpacket.

FIG. 1 illustrates an example mobile ad hoc network in which geogamingmay be implemented. Communications devices (nodes) in the mobile ad hocnetwork can communicate via RF encoded with geographic information, viaBluetooth technology, via WiFI (e.g., in accordance with the 802.11standard), or the like, or any combination thereof. For example, asdepicted in FIG. 1, communication devices 12, 14, 16, 18, and 20 form amobile ad hoc network. As shown in FIG. 1, communication device 12communicates with communications device 14 directly (e.g., viaBluetooth). Communication device 14 communicates with communicationsdevice 16, and thus can retransmit information received fromcommunications device 12 to communications device 16, and vice versa(retransmit information received from communications device 16 tocommunications device 12). Communications device 16 communicates withcommunications devices 18 and 20, and can relay information from/tocommunications devices 18 and/or 20 to/from communications devices 12and/or 14.

Although not depicted in FIG. 1, it is possible, in a mobile ad hocnetwork, that, for a pair of nodes (A and B for example), node A canreceive from node B but node B can not receive from node A. Thisasymmetric style of communication is potential likely in a mobile ad hocnetwork.

In an example embodiment, communications devices that receive a messagecan resend the message in accordance with the scalable wireless geocastprotocol. For example, a communication device's ability to retransmit amessage can be based on the number of times the message was previouslyreceived, the communication device's proximity with respect to thecommunications devices from which the message was sent, and/or thecommunication device's proximity to the geocast region. This can beimplemented as a three step location-based approach, which is describedin detail in the aforementioned U.S. Pat. No. 7,525,933, entitled“System And Method For Mobile Ad Hoc Network,” filed Nov. 30, 2005,issued Apr. 28, 2009. First, in accordance with the location-basedapproach, the receiving communication device determines whether it haspreviously received the same message at least a predetermined number (N)of times. If not, it retransmits the message over the ad hoc network ofcommunications devices. If so, the communications device progresses tothe second step and determines whether the sending communications deviceis closer than some minimum distance away. If no prior transmitter ofthe message was closer than some minimum distance away, thecommunications device retransmits the message over the ad hoc network ofcommunications devices. Otherwise, the communications device progressesto the third step and determines whether it is closer to the center ofthe geocast region than any sending communications device from which themessage was received. If so, the communications device transmits themessage over the ad hoc network of communications devices. If not, thecommunications device does not retransmit the message.

This location-based approach prevents the receiving communicationsdevice from retransmitting a message that was most likely alreadyretransmitted by another communications device located close to it (andthus most likely reaching the same neighboring communications devicesthat it can reach). In addition, this location-based approach reducesthe chance that the communications device will retransmit the samemessage multiple times to the same neighboring communications devices.

As mentioned above, a mobile ad hoc network does not require acommunications network infrastructure or a WiFi access point. However,in an example configuration, a mobile ad hoc network can utilize WiFiaccess points and/or a communications network infrastructure.

FIG. 2 illustrates example communications in an ad hoc network in whichgeogaming can be implemented via a WiFi access point. As depicted inFIG. 2, communication devices 26, 28, 30, 36, and 38 form a mobile adhoc network and communication device 32 and 34 form another mobile adhoc network. Coverage area 22, which is the area covered by a WiFiaccess point 40, covers communication devices 26 and 28. Coverage area24, which is the area covered by another WiFi access point 42 coverscommunication device 32. As shown in FIG. 2, communication device 34transmits to communication device 32 directly (e.g., via Bluetooth).Communication device 32 retransmits to a WiFi access point 42 which inturn retransmits to the other WiFi access point 40. Communicationdevices 26 and 28 receive the transmission from the WiFi access point40, and communication device 28 retransmits directly to communicationdevice 30. And, as depicted, communication device 30 retransmits toother communication devices 36 and 38.

FIG. 3 illustrates an example mobile ad hoc network in which geogamingcan be implemented utilizing tiered geocasting and forwarding zones.Tiered geocasting uses long range (LR) transmitters (such ascommunications devices, etc), infrastructure, a communications network,a cellular tower, or a combination thereof, when available. Tieredgeocasting assumes that at least one tier is usable by at least one ofthe communications devices. A long range tier is a tier whereincharacteristic message transfers between devices occur over a longerphysical range than those over some other tier. A long range tier can bewireless, wired, or a combination thereof.

A forwarding zone can be utilized to implement tiered geocasting. Acommon forwarding zone can be defined for all geocast packets ordifferent forwarding zones can be defined for each type of geocastpacket. Forwarding zones (as shown in FIG. 3, for example and withoutlimitation) can be defined differently in different tiers, even for thesame packet type or even same packet. Thus, forwarding heuristics can beapplied independently per tier, with bridging at multi-tier capablenodes. In an example embodiment, a communications device retransmits apacket only if the communications device is located within theforwarding zone defined for the packet's type. This determination is inaddition to the determinations described above and, if thecommunications device is not in the forwarding zone, the packet will notbe retransmitted, even if one or more of the above conditions wouldotherwise have caused a retransmission hold.

As depicted in FIG. 3, nodes (e.g., communications devices) D1, D2, D3,D4, D5, D6, and D7, are at various locations within short range (SR) andlong range (LR) tiers. All of devices D1, D2, D3, D4, D5, D6, and D7together form a mobile ad hoc network, with devices D5, D6, and D7 beinglocated in geocast region Y, hence being targets of a message sent byD1. Each communications device D1, D2, D3, D4, D5, D6, and D7 candetermine its own geographical location through any type of locationdetermination system including, for example, the Global PositioningSystem (GPS), assisted GPS (A-GPS), time difference of arrivalcalculations, configured constant location (in the case of non-movingnodes), any combination thereof, or any other appropriate means. Eachcommunications device is operable to transmit and receive packets on amobile ad hoc network. In addition, at any given time, some subset(possibly all) of the communications devices may be operable to transmitand receive packets over the long range tier network. For example,though not a limitation, in FIG. 3, devices D2, D3, and D4 can transmitand receive messages over both the short and long range tiers. Note thatthis latter fact is indicated visually in the diagram by D2, D3, and D4each having two dots (one in the short range tier and one in the longrange tier) connected by a vertical line. The long-rang tier network canbe any network in which packets can be transmitted from one long rangecapable communications device to another long range capablecommunications device. Such packet networks can include, for example, aninfrastructure-based network comprising wireless base stations (for up-and down-link) operating on a separate frequency from that used by an adhoc network. In addition, the long rang tier network also could beimplemented simply as another instance of an ad hoc network usingdistinct radio frequencies and possibly longer radio ranges.

Communications device D1 transmits the message, and communicationsdevice D2 receives the transmission from communications device D1.Communications device D2 retransmits (transmission 2 a), within theshort range tier and in accordance with the heuristics for the shortrange forwarding zone (SRFZ) as well as within the long range tier(transmission 2 b). Communications D2, with long range transmissioncapability (in the long range tier) retransmits in the long range tieras well (transmission 2 b). Communications device D3 receives thetransmission 2 b from communications device D2 and retransmits (astransmission 3) in the long range tier only. Communications device D4receives the transmission 3 from communications device D3 andretransmits both on the long and short range tiers, resulting intransmission 4 a in the long range tier and 4 b in the short range tier.Communications device D5, within geocast region Y, receives thetransmission 4 a, and in turn retransmits (transmission 5) within thegeocast region Y. Transmission 5 is received by the other devices ingeocast region Y, namely devices D6 and D7, thus completing the geocastmessage transfer.

As described above, an example geogame is played within a geographicarea. Geocast origination, destination, and termination regions can bedefined by geographic parameters and may have any size and shape. Asexamples, the regions may be defined by three or more boundinggeographic coordinates, forming a triangle, rectangle, or other shape,or a single geographic coordinate and a radius or diameter, forming ageocast region.

Players can identify the geocast region directly or indirectly. In oneembodiment, an initiating player selects a region indirectly byidentifying a target player with whom the initiating player wishes toplay. The geocast region may be defined by the initiating WT, the targetWT, or other entity, such as a remote server facilitating gameinitiation and/or play. The geocast region may be defined, at least inpart, based on a location of the target WT. In various embodiments, thelocation of the target WT is obtained from the target WT or othersources such as from a network resource, like a home location register(HLR) to which the target WT is associated.

FIG. 4, comprising FIG. 4A-FIG. 4E depict example geocast regions orboundaries. A geocast region may be defined to be a single point 40, asdepicted in FIG. 4A. A point geocast region may be defined by alongitude value and a latitude value (not shown). A point above thesurface of the earth could be defined by providing an altitude value inaddition to longitude and latitude values. A geocast region may alsocomprise multiple single points (not shown) such as the single point 40.Location points such as point 40 may be used as the building blocks formore complex geocast region geometries, as described herein. FIG. 4Bdepicts a geocast region defined by a point 40 in combination with aradius 42. The geocast region of this example will comprise the areaenclosed by the radius, and may include the space above the area aswell. A geocast region could also be defined as the overlap regionbetween two or more circular geocast regions (not shown). FIG. 4Cdepicts a more complex geometry formed from a series of points 40interconnected with straight boundary lines. This technique of geocastregion definition is similar to the techniques typically used in thedefinition of parcels of real property. FIGS. 4D and 4E depict thecreation of one or more geocast regions within a single geographicfootprint. FIG. 4D depicts creating a geocast region for a specificfloor of a building 44. The single floor geocast region is defined asthe volume of space between upper and lower areas, each formed using aseries of points 40 set at corners of the buildings. FIG. 4E depicts analternate technique for defining a single floor geocast region inbuilding 44. Upper and lower points 40 are defined in the middle of theceiling and the floor of the geocast region respectively. The singlefloor geocast region is then defined as the volume of space between anupper area and a lower area defined by a pair of radii 42 extending fromthe middle points. Geocast regions may also be defined to change insize, geographic location, etc. with time (not shown), essentiallyallowing the creation of geocast geogaming regions in four dimensions.For example a geogaming region corresponding to a virtual playing fieldmay be defined to change size, shape, and/or geographic location overtime as the number of participating geogame players fluctuates.Information defining a particular geocast region (e.g., a series ofpoints) can be communicated in an addressing portion of a geogamingmessage. Geocast sub-regions may be defined within a particular geocastregion using the above techniques. It should be noted that thetechniques described with reference to FIGS. 4A-4E are merely examples,and the scope of the instant disclosure should not be limited thereto.Other geogaming region geometries and techniques for defining geogamingregions may be recognized by those skilled in the art, and are meant tobe included within the scope of the instant disclosure.

In some embodiments, a player can select a geocast region or the like,by making one or more selections on a map and/or from a list. Forexample, if a player on a college campus in New York wishes to initiateplay with one or more players located on a college campus in London, theinitiating player may select the campus in London, or a desired portionof the campus, such as a particular fraternity house selected by mapinput and/or from a list, as the geocast region, or the like.

FIG. 5 depicts a geogame player 45 located in a geogame play region asrendered on a wireless terminal, WT 200. As shown in FIG. 5, the playeris rendered on the wireless terminal, WT, as a circle with a dottherein. Players, however, can be rendered in any appropriate format.For example, players can be rendered in different colors, by differentshapes, via animation, via icons, via text, via numbers, via avatars, orthe like, or any combination thereof. The game play region can be anyappropriate region. In various embodiments, a player can define a regionby boundaries, select a region from a list of predetermined regions,define a region based on the player's geographical location, or anycombination thereof.

FIG. 6 depicts “good” virtual objects 50. For the sake of clarity, onlythree good virtual objects are designed with the number 50. As shown inFIG. 6, each good virtual object is rendered on the wireless terminal,WT 200, as a circle with an “X” therein. Good virtual objects, however,can be rendered in any appropriate format. For example, good virtualobjects can be rendered in different colors, by different shapes, viaanimation, via icons, via text, via numbers, via avatars, or the like,or any combination thereof.

FIG. 7 depicts “bad” virtual objects 52. For the sake of clarity, onlythree bad virtual objects are designed with the number 52. As shown inFIG. 7, each bad virtual object is rendered on the wireless terminal, WT200, as a circle with an “Y” therein. Bad virtual objects, however, canbe rendered in any appropriate format. For example, bad virtual objectscan be rendered in different colors, by different shapes, via animation,via icons, via text, via numbers, via avatars, or the like, or anycombination thereof.

In an example configuration, virtual objects can be rendered ascreatures or imaginary entities, such as butterflies, fireflies, moths,birds, fairies, or the like. Creatures can be rendered as good creaturesand bad creatures. And, as the creatures/entities appear to fly and/orfloat, players capture and/or avoid the creatures/entities per rules ofthe geogame.

FIG. 8 depicts good virtual objects 50 and bad virtual objects 52located in a player's game play region as depicted on WT 200.

FIG. 9 depicts another geogame player 47 located in the same geogameplay region as player 45, along with good virtual objects 50 and badvirtual objects 52, as rendered on a wireless terminal, WT 200. As shownin FIG. 9, the player 47 is rendered on the wireless terminal, WT, as asquare with a dot therein. Players, however, can be rendered in anyappropriate format. For example, players can be rendered in differentcolors, by different shapes, via animation, via icons, via text, vianumbers, via avatars, or the like, or any combination thereof. The gameplay region can be any appropriate region. In various embodiments, aplayer can define a region by boundaries, select a region from a list ofpredetermined regions, define a region based on the player'sgeographical location, or any combination thereof. As shown in FIG. 9,geogame player 9 is playing the geogame in the same geographic region asgeogame player 45. However, as described in more detail below, this isnot necessary.

FIG. 10 depicts an example location and boundary of a virtual object. Asdepicted in FIG. 10 on WT 200, the geographic boundary associated withthe location of the virtual object 54 is defined by the border 56. Thevirtual object 54 is denoted by the letter “V” so as not to beconsidered a good or bad virtual object, but rather a generic virtualobject for the purpose of this discussion. Border 56 can define an areaor a volume. Thus, the circle depicted as the perimeter 56 of virtualobject 54 can represent any appropriate two or three dimensional shape,such as, for example, a circle, an ellipse, a sphere, an ellipsoid, aspheroid, or the like. Similarly, a player can represent a threedimensional player. Thus, the circle depicted on the perimeter of player45, which represent the boundary of the player 45, can represent anyappropriate two or three dimensional shape, such as, for example, acircle, an ellipse, a sphere, an ellipsoid, a spheroid, or the like.

Virtual objects can represent two or three-dimensional objects that arefloating, flying, rolling, moving, remaining stationary, or the like.Accordingly, in a example embodiment, if a virtual object is floating orflying, a player may have to jump to capture a good virtual object. Or aplayer may be able to duck to avoid a bad virtual object. As depicted inFIG. 10, two players 43 and 45 intersect the boundary of the virtualobject 54. That is, the location of each of the two players 43 and 45 iscoincident with a portion of the virtual space occupied by the volume(or area if two dimensional) defined by the border 56. A boundary of avirtual object is the virtual space occupied by the virtual object asdefined by the border 56. Thus, a player intersects the boundary of avirtual object if the location of the player intersects the border ofthe boundary or if the location of the player is within the border, asdepicted in FIG. 10. According to the rules of the geogame, if thevirtual object 54 is a good virtual object, has captured the virtualobject 54. If however, the virtual object 54 is a bad virtual object,the player will loses a point or points. In an example embodiment, aplayer whose device is within the boundary of a bad virtual object willcontinue to lose points as long as the player is within the boundary.Thus, to avoid losing more points, the player must move away from (moveout of the boundary of) the bad virtual object.

FIG. 11 depicts renderings of multiple players and multiple virtualobjects in different, distinct, physical locations. As shown in FIG.11A, geogame region 48 a is physically located in a field in New Jersey.As shown in FIG. 11B, geogame region 48 b is physically located in afield in Pennsylvania. In an example scenario, as depicted in FIG. 11,player 45 has selected region 48 a. When player 47 joins the geogame,the location of player 47 is determined and a corresponding region 48 bis determined for player 47. In various example embodiments, the area,volume, and/or dimensions of multiple regions can be the same or differ.After the geogame starts, locations of player's and virtual objects arerendered on each player's WT. The locations of players and virtualobjects are appropriately correlated to be rendered similarly with theboundary/region being rendered.

According to the rules of the geogame, player 45 is to capture goodvirtual objects 50 (circled Xs) to obtain points, and is to avoid badvirtual object 52 (squared Xs) to avoid losing points, located in thegeogame region 48 a. And, player 47 is to capture good virtual objects50 (circled Xs) to obtain points, and is to avoid bad virtual object 52(squared Xs) to avoid losing points, located in the geogame region 48 b.A virtual object is captured when the boundary of the physicalgeographic location of a device being used by player is determined tointersect the boundary of the geographic location associated with a goodvirtual object. And a player loses points when the boundary of thephysical geographic location of a device being used by player isdetermined to intersect the boundary of the geographic locationassociated with a bad virtual object. Each virtual object has ageographic location and boundary associated therewith.

FIG. 12 depicts a good virtual object 50 being converted to an attackvirtual object 58. In one example embodiment, when a good virtual objectis captured, the good virtual object is removed from game play. In anexample embodiment involving multiple players, when a player captures agood virtual object, the captured good virtual object can be convertedto an “attack” virtual object. As depicted in FIG. 12A, geogame player45 has captured good virtual object 50. In response to being captured,the good virtual object 50 is converted to an attack virtual object 58as depicted in FIG. 12B. An attack virtual object represents a badvirtual object for all other players of the geogame other than theplayer who converted the virtual object. And, an attack virtual objectis essentially a neutral virtual object for the converting geogameplayer. Thus, if the converting player “touches” the virtual object (theboundary of the location of the converting geogame player intersects theboundary of the attack virtual object), the converting player does notlose points and the converting player does not gain points.

An attack virtual object, can remain stationary, can move in apredetermined pattern, can mover in a non-predetermined pattern (e.g.,random), and/or can move toward other players of the geogame. When theboundary of an attack virtual object intersects the boundary of anothergeogame player, the other geogame player loses points.

In an various example configurations, a bad virtual object can beremoved from game play when a player touches (the boundary of thelocation of the geogame player intersects the boundary of the virtualobject) the bad virtual object, a bad virtual object can remain in gameplay, and the player touching the bad virtual object can continue tolose point until that player moves away from the bad virtual object, orany combination thereof.

In an various example configurations, an attack virtual object can beremoved from game play when a player touches (the boundary of thelocation of the geogame player intersects the boundary of the virtualobject) the attack virtual object, an attack virtual object can remainin game play, and the player touching the attack virtual object cancontinue to lose point until that player moves away from the attackvirtual object, or any combination thereof.

Virtual objects can remain stationary and/or move in various ways. Forexample, virtual objects can be stationary, move in accordance withdeterministic pattern, move in accordance with non-deterministic motion(e.g., randomly), or any combination thereof. Thus, some virtual objectscan be stationary, others can move deterministically, and others canmove non-deterministically.

FIG. 13 depicts a list from which a player can select a destination,termination, boundary, region, or the like. As shown in FIG. 13, aplayer can select a destination, termination, boundary, region, or thelike from a list 62 displayed on mobile communications device. The listcan comprise real world locations, virtual locations, or any combinationthereof. For example, as depicted, item 64 on the list 62 represents areal world location—a building. Item 66 on the list 62 represent avirtual field designated filed 100. A player can search items on thelist in any appropriate manner. For example, a player can scroll throughthe list by touching the display surface of device, by providing a voicecommand (e.g., “Scroll List”), by entering text on which to search, bymoving the device, or any appropriate combination thereof.

In an example embodiment, the selection of a destination, termination,boundary, region, or the like can be made by selecting a location on themap by a finger, fingers, and/or any other appropriate device, and, forexample, dragging away or gesture-pinching, from the selected locationto create the size of the a circle, oval, rectangular, square, polygon,or any appropriate shape (two dimensional or three dimensional)representing a destination, termination, boundary, region, or the like.In various example embodiments, locations, such as addresses, and/orregion dimensions, building names, institution names, landmarks, etc.may be input in other ways by a player, such as by typing, gesture,and/or voice input.

FIG. 14 depicts a position 68 of a user 45 on a map displayed on WT 200.Before a user joins a game, the user can indicate his/her position bytapping a point on a map with a finger and/or any appropriate device. Inanother example embodiment, a user can enter coordinates or anyappropriate indication of a location via text, voice, gesture, or anyappropriate combination thereof.

FIG. 15 depicts an example rendering of a start time of a geogame. In anexample embodiment, a user can tap the join indicator 70, and the starttime will be rendered on the WT 200. The start time can be renderedvisually, audibly, mechanically (vibration), or any combination thereof.The start time can be rendered in any appropriate format. For example,the start time can be a time of day (e.g. 4:05 PM Eastern StandardTime), a count down timer (e.g., time remaining until start of geogamein seconds, minutes, hours, days, etc.), or the like. As depicted inFIG. 10, a user has tapped join indicator 70 and a rendering on thedisplay of WT 50 as shown in display area 64, indicates that the geogamewill start in 16 seconds. As time progresses, the indication of time indisplay are 72 will decrement to zero. At time zero, the game begins.

FIG. 16 is an example depiction of multiple players having joined thegeogame. Others can join the game prior to start time. As depicted inFIG. 16, players 74 and 76 have joined the game. The respectivelocations of players 74 and 76 are rendered on the WT 200. As a playerjoins the geogame, the location of the player is determined and geocast.Other WTs in the geocast region will receive the geocast messagecomprising the locations of the other players.

FIG. 17 is a flow diagram of an example process for playing a geogame. Aplayer joins the geogame at step 80. At step 82, the boundary for eachvirtual object in the geogame is determined. In an example embodiment, amobile device (e.g., WT 200) receives information indicative of thelocation of each virtual object in the geogame. And, the mobile devicedetermines the boundary of each virtual object in the geogame. Inanother example embodiment, a processor receives the location of eachvirtual in the geogame, determines the boundary of each virtual objectin the geogame, and provides information indicative of the boundary ofeach virtual object in the geogame. The processor can be one of themobile devices participating in the geogame, a processor other than oneof the mobile devices, or any combination thereof.

Each mobile device participating in the geogame determines its currentlocation at step 84. At step 86, each mobile device geocasts its currentlocation. Thus, each mobile device participating in the geogame shouldreceive an indication of the current location of all other mobiledevices participating in the geogame.

At step 88, each mobile device participating in the geogame determinesif the boundary of its currently location intersects with a boundary ofany of the virtual objects in the geogame. If, at step 90, it isdetermined that the boundary of a mobile device does not intersect theboundary of a virtual object, it is determined, at step 114 if the gameis over for that player. If the game is over for that player, the gameends for that player at step 116. If the game is not over for thatplayer, the process proceeds to step 82 and, for that player continuestherefrom.

If, at step 90, it is determined that the boundary of a mobile deviceintersects the boundary of a virtual object, the type of virtual objectis determined at step 92. The type of object can be, for example, good,bad, or attack, as previously described. If it is determined, at step92, that the type of virtual object is good, the player utilizing themobile device to participate in the geogame is rewarded at step 94. Areward can include a point or points added to the player's score. Areward can include time added to a player's game play time. For example,if game players are provided a fixed amount of time to play a game, andthe winner of the game is the player with the most points when the gameis over, a reward for capturing a good virtual object could be to addtime (e.g., seconds, minutes, hours) to the player's time allotted forgame play.

At step 96, it is determined if the captured virtual object is to beconverted to an attack object. If, at step 96, it is determined that thecaptured virtual object is to be converted to an attack object, thecaptured object is converted to an attack object at step 98. From step98, it is determined, at step 114 if the game is over for the particularplayer. If the game is over for the particular player, the game ends,for that player at step 116. If the game is not over for that player,the process proceeds to step 82 and, for that player, continuestherefrom. If, at step 96, it is determined that the captured virtualobject is not to be converted to an attack object, the captured objectis removed from game play at step 1008. From step 100, it is determined,at step 114 if the game is over for the particular player. If the gameis over for the particular player, the game ends, for that player atstep 116. If the game is not over for that player, the process proceedsto step 82 and, for that player, continues therefrom.

If, at step 92, it is determined that the type of virtual object is nota good object, it is determined, at step 102, if the object is a badvirtual object of an attack virtual object. If it is determined, at step102, that the virtual object is an attack virtual object, it isdetermined, at step 104, if the player (whose current location boundaryintersected the virtual object boundary) was the player who convertedthe good virtual object to an attack virtual object (converting player)at step 104. If it is determined, at step 104, that the player is theconverting player, it is determined at step 114, if the game is over forthat player. If the game is over for that player, the game ends, forthat player at step 116. If the game is not over for that player, theprocess proceeds to step 82 and, for that player, continues therefrom.

If it is determined, at step 104, that the player (whose currentlocation boundary intersected the virtual object boundary) was not theplayer who converted the good virtual object to an attack virtual object(not the converting player), the player is penalized at step 106. Apenalty can include a point or points be removed from the player'sscore. A penalty can include time be removed from a player's game playtime. For example, if game players are provided a fixed amount of timeto play a game, and the winner of the game is the player with the mostpoints when the game is over, a penalty for touching a bad or attackgood virtual object could be to remove time (e.g., seconds, minutes,hours) from the player's time allotted for game play.

At step 108, it is determined if the virtual object (bad or attackvirtual object) is to be removed from game play. If it is determined, atstep 108, that the virtual object is to be removed from game play, thevirtual object is removed from game play at step 110. From step 110, itis determined, at step 114 if the game is over for the particularplayer. If the game is over for the particular player, the game ends,for that player at step 116. If the game is not over for that player,the process proceeds to step 82 and, for that player, continuestherefrom.

If it is determined, at step 108, that the virtual object is not to beremoved from game play, the virtual object stays in game play asdepicted in step 112. From step 112, it is determined, at step 114 ifthe game is over for the particular player. If the game is over for theparticular player, the game ends, for that player at step 116. If thegame is not over for that player, the process proceeds to step 82 and,for that player, continues therefrom.

If it is determined, at step 102, that the virtual object is a badvirtual object, it is determined, at step 104, the player is penalizedat step 106. A penalty can include a point or points be removed from theplayer's score. A penalty can include time be removed from a player'sgame play time. For example, if game players are provided a fixed amountof time to play a game, and the winner of the game is the player withthe most points when the game is over, a penalty for touching a bad orattack good virtual object could be to remove time (e.g., seconds,minutes, hours) from the player's time allotted for game play.

At step 108, it is determined if the virtual object (bad or attackvirtual object) is to be removed from game play. If it is determined, atstep 108, that the virtual object is to be removed from game play, thevirtual object is removed from game play at step 110. From step 110, itis determined, at step 114 if the game is over for the particularplayer. If the game is over for the particular player, the game ends,for that player at step 116. If the game is not over for that player,the process proceeds to step 82 and, for that player, continuestherefrom.

If it is determined, at step 108, that the virtual object is not to beremoved from game play, the virtual object stays in game play asdepicted in step 112. From step 112, it is determined, at step 114 ifthe game is over for the particular player. If the game is over for theparticular player, the game ends, for that player at step 116. If thegame is not over for that player, the process proceeds to step 82 and,for that player, continues therefrom.

FIG. 18, which illustrates the relationship between event history andstate values, in an example embodiment, a global event history comprisesthe union of events for each player of the geogame. For example, asdepicted in FIG. 19, a global event history stored on player 1's devicecan include player 1's own event history and the event history of eachother player. An event can comprise any appropriate event, such as forexample, a position (location) determined at a particular time, a userinterface (UI) event (e.g., screen tap at a particular time, etc.), or acombination thereof. A global event history is operated on by afunction, depicted as function “f” in FIG. 19, to determine stat values.A state value can include any appropriate state value, such as forexample, the state of a virtual object (e.g., good, bad, attack,captured, if flying object: wings open or wings closed, etc.), the stateof a player (e.g., intersect a boundary, not intersecting anyboundaries, penalized, rewarded, score, etc.).

In an example embodiment, a global event history is partitioned in timesegments, referred to herein as epochs. FIG. 19 is an depiction ofepochs for multiple players. An epoch can represent any appropriateperiod of time. For example, an epoch can comprise a discrete period oftime (e.g., 100 milliseconds), a proportional period of time (e.g.,proportional to game length, device clock rate, etc.), or a combinationthereof. In an example configuration, the time covered by an epoch isdetermined to ensure that one position change (position and time), atmost, and/or another event (e.g. UI event), occurs during the epoch. Forexample, referring to FIG. 19, for player 1, during epoch 1, a position,a time associated with the position and a UI event (e.g., tap on thedisplay of the device) shown. The subscript shown indicates the epochand player. It is to be understood that the depiction of a global eventhistory as shown in FIG. 19 is exemplary, and is not to be construed aslimiting thereto.

The function, f, determines derived state values from global eventhistory. In an example embodiment, the function, f, determines newpositions and states for each virtual object and determines a score foreach player. For each virtual object, in order to determine a virtualobject's position in the next epoch (i+1), the function, f, determinesthe virtual object's position (recursively) in the current epoch (i).The function, f, then applies events from the next epoch (i+1) of theglobal event history and state values of the virtual object (k). Theresult is a new position and state values for the virtual object(VO_(k)). For example, a virtual object (VO_(k)) couf move 2 metersnorth and switch from wings open to wings closed. Initial positions andstate values can be predetermined and/or calculated. In another examplescenario, for each epoch (i), the function, f, can determine whether aplayer intersects a boundary of a virtual object (VO_(k)), and if so,for good virtual objects, the earliest player to become so positioned isthe scorer and obtains points, and for bad virtual objects, all playersso positioned incur penalties. And, if the virtual object is captured,the first player so positioned captures the virtual object.

FIG. 20 is another flow diagram of an example process for playing ageogame. At step 120, the state of the geogame is initialized. At step122, the geogame is set up. In an example configuration, setting upcomprises declaring (e.g., by an originator of the geogame) an area ofplay and a start time. All devices can compute a time correction inorder to synchronize their respective clocks to the official “gametime.”

At step 124, it is determined if the geogame is started. If it isdetermined, at step 124, that the game has not started, the processremains at step 124 to continue to determine if the geogame has started.If, it is determined, at step 124, that the game has started, theprocess proceeds to steps 126, 142, and 152, to concurrently execute therespective subsequent steps. That is, the three groups of steps (126,128, 130, 132, 134, 136, and 138), (142, 146, 148, and 150), and (152,154, 156, and 158) can run concurrently.

At step 126, it is determined if an event has occurred, and the type ofevent. An event can comprise any appropriate event, such as for example,a position change, a UI event, a game ending event, an event historyfrom another player/device, or the like, or a combination thereof. If itis determined, at step 126, that an event has occurred, and that theevent is a game ending event, the game is ended, for that device, atstep 138. A game ending event can comprising any appropriate game endingevent, such as for example, a game over event and/or expiration of timeevent (e.g., game time expired, level time expired, etc.) has occurred.

If, at step 126, it is determined that an event has occurred, and thatthe event is an event history from another player/device, the eventhistory is received at step 128. The event history from the otherplayer/device is merged with the event history of the receivingplayer/device at step 130. Geogame states are computed (e.g., updatedwith the merged event history) at step 132. From step 132, the processproceeds to step 126.

If, at step 126, it is determined that an event has occurred, and thatthe event comprises location information, an indication to updatelocation, and/or a UI event, the location of the device is determined atstep 134. At step 136, the event history of the device is augmented withthe newly determined location information. And, geogame states arecomputed (e.g., updated with the augmented event history) at step 132.From step 132, the process proceeds to step 126.

Concurrently (e.g., with steps 126, 128, 130, 132, 134, 136, 138 andwith steps 152, 154, 156, 158), it is determined, at step 142, if atransmit occasion has occurred. If it is determined, at step 142, that atransmit occasion has occurred (e.g., an opportunity to transmit), thedevice geocasts its event history at step 146. If it is determined, atstep 142, that a transmit occasion has not occurred (e.g., noopportunity to transmit), it is determined, at step 148, if a gameending event has occurred. If, at step 148, it is determined that a gameending event has occurred, the game is ended, for that device, at step150. If, at step 148, it is determined that a game ending event has notoccurred, the process proceeds to step 142.

Concurrently (e.g., with steps 126, 128, 130, 132, 134, 136, 138 andwith steps 152, 154, 156, 158), it is determined, at step 152, if ascreen refresh occasion has occurred. If it is determined, at step 152,that a screen refresh occasion has occurred (e.g., an opportunity torefresh the display of the device), the screen (e.g., display of thedevice) is refreshed at step 154. If it is determined, at step 152, thata screen refresh occasion has not occurred (e.g., no opportunity torefresh the display of the device), it is determined, at step 156, if agame ending event has occurred. If, at step 156, it is determined that agame ending event has occurred, the game is ended, for that device, atstep 158. If, at step 156, it is determined that a game ending event hasnot occurred, the process proceeds to step 152.

FIG. 21 is a block diagram of an example communications device (alsoreferred to as a node, or wireless terminal, WT) 220 configured tofacilitate geogaming. In an example configuration, communications device220 is a mobile wireless device. The communications device 220 cancomprise any appropriate device, examples of which include a portablecomputing device, such as a laptop, a personal digital assistant(“PDA”), a portable phone (e.g., a cell phone or the like, a smartphone, a video phone), a portable email device, a portable gamingdevice, a TV, a DVD player, portable media player, (e.g., a portablemusic player, such as an MP3 player, a walkmans, etc.), a portablenavigation device (e.g., GPS compatible device, A-GPS compatible device,etc.), or a combination thereof. The communications device 220 caninclude devices that are not typically thought of as portable, such as,for example, a public computing device, a navigation device installedin-vehicle, a set top box, or the like. The mobile communications device220 can include non-conventional computing devices, such as, forexample, a kitchen appliance, a motor vehicle control (e.g., steeringwheel), etc., or the like. As evident from the herein description, anode, and thus a communications device, is not to be construed assoftware per se.

The communications device 220 can include any appropriate device,mechanism, software, and/or hardware for facilitating a geogame asdescribed herein. In an example embodiment, the ability to facilitate ageogame is a feature of the communications device 220 that can be turnedon and off. Thus, an owner/user of the communications device 220 canopt-in or opt-out of this capability.

In an example configuration, the communications device 220 comprises aprocessing portion 222, a memory portion 224, an input/output portion226, and a user interface (UI) portion 228. It is emphasized that theblock diagram depiction of communications device 220 is exemplary andnot intended to imply a specific implementation and/or configuration.For example, in an example configuration, the communications device 220comprises a cellular phone and the processing portion 222 and/or thememory portion 224 are implemented, in part or in total, on a subscriberidentity module (SIM) of the mobile communications device 220. Inanother example configuration, the communications device 220 comprises alaptop computer. The laptop computer can include a SIM, and variousportions of the processing portion 222 and/or the memory portion 224 canbe implemented on the SIM, on the laptop other than the SIM, or anycombination thereof.

The processing portion 222, memory portion 224, and input/output portion226 are coupled together to allow communications therebetween. Invarious embodiments, the input/output portion 226 comprises a receiverof the communications device 220, a transmitter of the communicationsdevice 220, or a combination thereof. The input/output portion 226 iscapable of receiving and/or providing information pertaining geogamingas described above. For example, the communications device 220 iscapable of sending geocasts and receiving geocasts. In variousconfigurations, the input/output portion 226 can receive and/or provideinformation via any appropriate means, such as, for example, opticalmeans (e.g., infrared), electromagnetic means (e.g., RF, WI-FI,BLUETOOTH, ZIGBEE, etc.), acoustic means (e.g., speaker, microphone,ultrasonic receiver, ultrasonic transmitter), or a combination thereof.

The processing portion 222 is capable of performing functions pertainingto geogaming as described above. In a basic configuration, thecommunications device 220 can include at least one memory portion 224.The memory portion 224 is a storage medium having a tangible physicalstructure. The memory portion 224 can store any information utilized inconjunction with geogaming as described above. Depending upon the exactconfiguration and type of processor, the memory portion 224 can bevolatile (such as some types of RAM), non-volatile (such as ROM, flashmemory, etc.), or a combination thereof. The mobile communicationsdevice 220 can include additional storage (e.g., removable storageand/or non-removable storage) including, but not limited to, tape, flashmemory, smart cards, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, universal serial bus (USB)compatible memory, or any other medium which can be used to storeinformation and which can be accessed by the mobile communicationsdevice 220.

The communications device 220 also can contain a user interface (UI)portion 228 allowing a user to communicate with the communicationsdevice 220. The UI portion 228 is capable of rendering any informationutilized in conjunction with geogaming as described above. The UIportion 228 can provide the ability to control the communications device220, via, for example, buttons, soft keys, voice actuated controls, atouch screen, movement of the mobile communications device 220, visualcues (e.g., moving a hand in front of a camera on the mobilecommunications device 220), or the like. The UI portion 228 can providevisual information (e.g., via a display), audio information (e.g., viaspeaker), mechanically (e.g., via a vibrating mechanism), or acombination thereof. In various configurations, the UI portion 228 cancomprise a display, a touch screen, a keyboard, an accelerometer, amotion detector, a speaker, a microphone, a camera, a tilt sensor, orany combination thereof. The UI portion 228 can comprise means forinputting biometric information, such as, for example, fingerprintinformation, retinal information, voice information, and/or facialcharacteristic information.

The UI portion 228 can include a display for displaying multimedia suchas, for example, virtual objects, players, application graphical userinterfaces (GUIs), text, images, video, telephony functions such asCaller ID data, setup functions, menus, music, metadata, messages,wallpaper, graphics, Internet content, device status, preferencessettings, map and location data, routes and other directions, points ofinterest (POI), and the like.

In some embodiments, the UI portion can comprise a user interface (UI)application. The UI application interfaces with a client or operatingsystem (OS) to, for example, facilitate user interaction with devicefunctionality and data. The UI application can aid a user in enteringmessage content, viewing received messages, answering/initiating calls,entering/deleting data, entering and setting user IDs and passwords,configuring settings, manipulating address book content and/or settings,interacting with other applications, or the like, and may aid the userin inputting selections and maneuvers associated with geogaming asdescribed herein.

Although not necessary to implement geogaming, a communications devicecan be part of and/or in communications with various wirelesscommunications networks. Some of which are described below.

FIG. 22 depicts an overall block diagram of an exemplary packet-basedmobile cellular network environment, such as a GPRS network, withinwhich geogaming can be implemented. In the exemplary packet-based mobilecellular network environment shown in FIG. 22, there are a plurality ofBase Station Subsystems (“BSS”) 800 (only one is shown), each of whichcomprises a Base Station Controller (“BSC”) 802 serving a plurality ofBase Transceiver Stations (“BTS”) such as BTSs 804, 806, and 808. BTSs804, 806, 808, etc. are the access points where users of packet-basedmobile devices become connected to the wireless network. In exemplaryfashion, the packet traffic originating from user devices is transportedvia an over-the-air interface to a BTS 808, and from the BTS 808 to theBSC 802. Base station subsystems, such as BSS 800, are a part ofinternal frame relay network 810 that can include Service GPRS SupportNodes (“SGSN”) such as SGSN 812 and 814. Each SGSN is connected to aninternal packet network 820 through which a SGSN 812, 814, etc. canroute data packets to and from a plurality of gateway GPRS support nodes(GGSN) 822, 824, 826, etc. As illustrated, SGSN 814 and GGSNs 822, 824,and 826 are part of internal packet network 820. Gateway GPRS servingnodes 822, 824 and 826 mainly provide an interface to external InternetProtocol (“IP”) networks such as Public Land Mobile Network (“PLMN”)850, corporate intranets 840, or Fixed-End System (“FES”) or the publicInternet 830. As illustrated, subscriber corporate network 840 may beconnected to GGSN 824 via firewall 832; and PLMN 850 is connected toGGSN 824 via boarder gateway router 834. The Remote AuthenticationDial-In User Service (“RADIUS”) server 842 may be used for callerauthentication when a user of a mobile cellular device calls corporatenetwork 840.

Generally, there can be a several cell sizes in a GSM network, referredto as macro, micro, pico, femto and umbrella cells. The coverage area ofeach cell is different in different environments. Macro cells can beregarded as cells in which the base station antenna is installed in amast or a building above average roof top level. Micro cells are cellswhose antenna height is under average roof top level. Micro-cells aretypically used in urban areas. Pico cells are small cells having adiameter of a few dozen meters. Pico cells are used mainly indoors.Femto cells have the same size as pico cells, but a smaller transportcapacity. Femto cells are used indoors, in residential, or smallbusiness environments. On the other hand, umbrella cells are used tocover shadowed regions of smaller cells and fill in gaps in coveragebetween those cells.

FIG. 23 illustrates an architecture of a typical GPRS network withinwhich geogaming can be implemented. The architecture depicted in FIG. 23is segmented into four groups: users 950, radio access network 960, corenetwork 970, and interconnect network 980. Users 950 comprise aplurality of end users. Note, device 912 is referred to as a mobilesubscriber in the description of network shown in FIG. 23. In an exampleembodiment, the device depicted as mobile subscriber 912 comprises acommunications device (e.g., communications device 278). Radio accessnetwork 960 comprises a plurality of base station subsystems such asBSSs 962, which include BTSs 964 and BSCs 966. Core network 970comprises a host of various network elements. As illustrated in FIG. 23,core network 970 may comprise Mobile Switching Center (“MSC”) 971,Service Control Point (“SCP”) 972, gateway MSC 973, SGSN 976, HomeLocation Register (“HLR”) 974, Authentication Center (“AuC”) 975, DomainName Server (“DNS”) 977, and GGSN 978. Interconnect network 980 alsocomprises a host of various networks and other network elements. Asillustrated in FIG. 23, interconnect network 980 comprises PublicSwitched Telephone Network (“PSTN”) 982, Fixed-End System (“FES”) orInternet 984, firewall 988, and Corporate Network 989.

A mobile switching center can be connected to a large number of basestation controllers. At MSC 971, for instance, depending on the type oftraffic, the traffic may be separated in that voice may be sent toPublic Switched Telephone Network (“PSTN”) 982 through Gateway MSC(“GMSC”) 973, and/or data may be sent to SGSN 976, which then sends thedata traffic to GGSN 978 for further forwarding.

When MSC 971 receives call traffic, for example, from BSC 966, it sendsa query to a database hosted by SCP 972. The SCP 972 processes therequest and issues a response to MSC 971 so that it may continue callprocessing as appropriate.

The HLR 974 is a centralized database for users to register to the GPRSnetwork. HLR 974 stores static information about the subscribers such asthe International Mobile Subscriber Identity (“IMSI”), subscribedservices, and a key for authenticating the subscriber. HLR 974 alsostores dynamic subscriber information such as the current location ofthe mobile subscriber. Associated with HLR 974 is AuC 975. AuC 975 is adatabase that contains the algorithms for authenticating subscribers andincludes the associated keys for encryption to safeguard the user inputfor authentication.

In the following, depending on context, the term “mobile subscriber”sometimes refers to the end user and sometimes to the actual portabledevice, such as a mobile device, used by an end user of the mobilecellular service. When a mobile subscriber turns on his or her mobiledevice, the mobile device goes through an attach process by which themobile device attaches to an SGSN of the GPRS network. In FIG. 23, whenmobile subscriber 912 initiates the attach process by turning on thenetwork capabilities of the mobile device, an attach request is sent bymobile subscriber 912 to SGSN 976. The SGSN 976 queries another SGSN, towhich mobile subscriber 912 was attached before, for the identity ofmobile subscriber 912. Upon receiving the identity of mobile subscriber912 from the other SGSN, SGSN 976 requests more information from mobilesubscriber 912. This information is used to authenticate mobilesubscriber 912 to SGSN 976 by HLR 974. Once verified, SGSN 976 sends alocation update to HLR 974 indicating the change of location to a newSGSN, in this case SGSN 976. HLR 974 notifies the old SGSN, to whichmobile subscriber 912 was attached before, to cancel the locationprocess for mobile subscriber 912. HLR 974 then notifies SGSN 976 thatthe location update has been performed. At this time, SGSN 976 sends anAttach Accept message to mobile subscriber 912, which in turn sends anAttach Complete message to SGSN 976.

After attaching itself with the network, mobile subscriber 912 then goesthrough the authentication process. In the authentication process, SGSN976 sends the authentication information to HLR 974, which sendsinformation back to SGSN 976 based on the user profile that was part ofthe user's initial setup. The SGSN 976 then sends a request forauthentication and ciphering to mobile subscriber 912. The mobilesubscriber 912 uses an algorithm to send the user identification (ID)and password to SGSN 976. The SGSN 976 uses the same algorithm andcompares the result. If a match occurs, SGSN 976 authenticates mobilesubscriber 912.

Next, the mobile subscriber 912 establishes a user session with thedestination network, corporate network 989, by going through a PacketData Protocol (“PDP”) activation process. Briefly, in the process,mobile subscriber 912 requests access to the Access Point Name (“APN”),for example, UPS.com, and SGSN 976 receives the activation request frommobile subscriber 912. SGSN 976 then initiates a Domain Name Service(“DNS”) query to learn which GGSN node has access to the UPS.com APN.The DNS query is sent to the DNS server within the core network 970,such as DNS 977, which is provisioned to map to one or more GGSN nodesin the core network 970. Based on the APN, the mapped GGSN 978 canaccess the requested corporate network 989. The SGSN 976 then sends toGGSN 978 a Create Packet Data Protocol (“PDP”) Context Request messagethat contains necessary information. The GGSN 978 sends a Create PDPContext Response message to SGSN 976, which then sends an Activate PDPContext Accept message to mobile subscriber 912.

Once activated, data packets of the call made by mobile subscriber 912can then go through radio access network 960, core network 970, andinterconnect network 980, in a particular fixed-end system or Internet984 and firewall 988, to reach corporate network 989.

FIG. 24 illustrates an exemplary block diagram view of a GSM/GPRS/IPmultimedia network architecture within geogaming can be implemented. Asillustrated, the architecture of FIG. 24 includes a GSM core network1001, a GPRS network 1030 and an IP multimedia network 1038. The GSMcore network 1001 includes a Mobile Station (MS) 1002, at least one BaseTransceiver Station (BTS) 1004 and a Base Station Controller (BSC) 1006.The MS 1002 is physical equipment or Mobile Equipment (ME), such as amobile phone or a laptop computer that is used by mobile subscribers,with a Subscriber identity Module (SIM) or a Universal IntegratedCircuit Card (UICC). The SIM or UICC includes an International MobileSubscriber Identity (IMSI), which is a unique identifier of asubscriber. The BTS 1004 is physical equipment, such as a radio tower,that enables a radio interface to communicate with the MS. Each BTS mayserve more than one MS. The BSC 1006 manages radio resources, includingthe BTS. The BSC may be connected to several BTSs. The BSC and BTScomponents, in combination, are generally referred to as a base station(BSS) or radio access network (RAN) 1003.

The GSM core network 1001 also includes a Mobile Switching Center (MSC)1008, a Gateway Mobile Switching Center (GMSC) 1010, a Home LocationRegister (HLR) 1012, Visitor Location Register (VLR) 1014, anAuthentication Center (AuC) 1018, and an Equipment Identity Register(EIR) 1016. The MSC 1008 performs a switching function for the network.The MSC also performs other functions, such as registration,authentication, location updating, handovers, and call routing. The GMSC1010 provides a gateway between the GSM network and other networks, suchas an Integrated Services Digital Network (ISDN) or Public SwitchedTelephone Networks (PSTNs) 1020. Thus, the GMSC 1010 providesinterworking functionality with external networks.

The HLR 1012 is a database that contains administrative informationregarding each subscriber registered in a corresponding GSM network. TheHLR 1012 also contains the current location of each MS. The VLR 1014 isa database that contains selected administrative information from theHLR 1012. The VLR contains information necessary for call control andprovision of subscribed services for each MS currently located in ageographical area controlled by the VLR. The HLR 1012 and the VLR 1014,together with the MSC 1008, provide the call routing and roamingcapabilities of GSM. The AuC 1016 provides the parameters needed forauthentication and encryption functions. Such parameters allowverification of a subscriber's identity. The EIR 1018 storessecurity-sensitive information about the mobile equipment.

A Short Message Service Center (SMSC) 1009 allows one-to-one ShortMessage Service (SMS) messages to be sent to/from the MS 1002. A PushProxy Gateway (PPG) 1011 is used to “push” (i.e., send without asynchronous request) content to the MS 1002. The PPG 1011 acts as aproxy between wired and wireless networks to facilitate pushing of datato the MS 1002. A Short Message Peer to Peer (SMPP) protocol router 1013is provided to convert SMS-based SMPP messages to cell broadcastmessages. SMPP is a protocol for exchanging SMS messages between SMSpeer entities such as short message service centers. The SMPP protocolis often used to allow third parties, e.g., content suppliers such asnews organizations, to submit bulk messages.

To gain access to GSM services, such as speech, data, and short messageservice (SMS), the MS first registers with the network to indicate itscurrent location by performing a location update and IMSI attachprocedure. The MS 1002 sends a location update including its currentlocation information to the MSC/VLR, via the BTS 1004 and the BSC 1006.The location information is then sent to the MS's HLR. The HLR isupdated with the location information received from the MSC/VLR. Thelocation update also is performed when the MS moves to a new locationarea. Typically, the location update is periodically performed to updatethe database as location updating events occur.

The GPRS network 1030 is logically implemented on the GSM core networkarchitecture by introducing two packet-switching network nodes, aserving GPRS support node (SGSN) 1032, a cell broadcast and a GatewayGPRS support node (GGSN) 1034. The SGSN 1032 is at the same hierarchicallevel as the MSC 1008 in the GSM network. The SGSN controls theconnection between the GPRS network and the MS 1002. The SGSN also keepstrack of individual MS's locations and security functions and accesscontrols.

A Cell Broadcast Center (CBC) 14 communicates cell broadcast messagesthat are typically delivered to multiple users in a specified area. CellBroadcast is one-to-many geographically focused service. It enablesmessages to be communicated to multiple mobile phone customers who arelocated within a given part of its network coverage area at the time themessage is broadcast.

The GGSN 1034 provides a gateway between the GPRS network and a publicpacket network (PDN) or other IP networks 1036. That is, the GGSNprovides interworking functionality with external networks, and sets upa logical link to the MS through the SGSN. When packet-switched dataleaves the GPRS network, it is transferred to an external TCP-IP network1036, such as an X.25 network or the Internet. In order to access GPRSservices, the MS first attaches itself to the GPRS network by performingan attach procedure. The MS then activates a packet data protocol (PDP)context, thus activating a packet communication session between the MS,the SGSN, and the GGSN.

In a GSM/GPRS network, GPRS services and GSM services can be used inparallel. The MS can operate in one of three classes: class A, class B,and class C. A class A MS can attach to the network for both GPRSservices and GSM services simultaneously. A class A MS also supportssimultaneous operation of GPRS services and GSM services. For example,class A mobiles can receive GSM voice/data/SMS calls and GPRS data callsat the same time.

A class B MS can attach to the network for both GPRS services and GSMservices simultaneously. However, a class B MS does not supportsimultaneous operation of the GPRS services and GSM services. That is, aclass B MS can only use one of the two services at a given time.

A class C MS can attach for only one of the GPRS services and GSMservices at a time. Simultaneous attachment and operation of GPRSservices and GSM services is not possible with a class C MS.

A GPRS network 1030 can be designed to operate in three networkoperation modes (NOM1, NOM2 and NOM3). A network operation mode of aGPRS network is indicated by a parameter in system information messagestransmitted within a cell. The system information messages dictates a MSwhere to listen for paging messages and how to signal towards thenetwork. The network operation mode represents the capabilities of theGPRS network. In a NOM1 network, a MS can receive pages from a circuitswitched domain (voice call) when engaged in a data call. The MS cansuspend the data call or take both simultaneously, depending on theability of the MS. In a NOM2 network, a MS may not received pages from acircuit switched domain when engaged in a data call, since the MS isreceiving data and is not listening to a paging channel. In a NOM3network, a MS can monitor pages for a circuit switched network whilereceived data and vise versa.

The IP multimedia network 1038 was introduced with 3GPP Release 5, andincludes an IP multimedia subsystem (IMS) 1040 to provide richmultimedia services to end users. A representative set of the networkentities within the IMS 1040 are a call/session control function (CSCF),a media gateway control function (MGCF) 1046, a media gateway (MGW)1048, and a master subscriber database, called a home subscriber server(HSS) 1050. The HSS 1050 may be common to the GSM network 1001, the GPRSnetwork 1030 as well as the IP multimedia network 1038.

The IP multimedia system 1040 is built around the call/session controlfunction, of which there are three types: an interrogating CSCF (I-CSCF)1043, a proxy CSCF (P-CSCF) 1042, and a serving CSCF (S-CSCF) 1044. TheP-CSCF 1042 is the MS's first point of contact with the IMS 1040. TheP-CSCF 1042 forwards session initiation protocol (SIP) messages receivedfrom the MS to an SIP server in a home network (and vice versa) of theMS. The P-CSCF 1042 may also modify an outgoing request according to aset of rules defined by the network operator (for example, addressanalysis and potential modification).

The I-CSCF 1043, forms an entrance to a home network and hides the innertopology of the home network from other networks and providesflexibility for selecting an S-CSCF. The I-CSCF 1043 may contact asubscriber location function (SLF) 1045 to determine which HSS 1050 touse for the particular subscriber, if multiple HSS's 1050 are present.The S-CSCF 1044 performs the session control services for the MS 1002.This includes routing originating sessions to external networks androuting terminating sessions to visited networks. The S-CSCF 1044 alsodecides whether an application server (AS) 1052 is required to receiveinformation on an incoming SIP session request to ensure appropriateservice handling. This decision is based on information received fromthe HSS 1050 (or other sources, such as an application server 1052). TheAS 1052 also communicates to a location server 1056 (e.g., a GatewayMobile Location Center (GMLC)) that provides a position (e.g.,latitude/longitude coordinates) of the MS 1002.

The HSS 1050 contains a subscriber profile and keeps track of which corenetwork node is currently handling the subscriber. It also supportssubscriber authentication and authorization functions (AAA). In networkswith more than one HSS 1050, a subscriber location function providesinformation on the HSS 1050 that contains the profile of a givensubscriber.

The MGCF 1046 provides interworking functionality between SIP sessioncontrol signaling from the IMS 1040 and ISUP/BICC call control signalingfrom the external GSTN networks (not shown). It also controls the mediagateway (MGW) 1048 that provides user-plane interworking functionality(e.g., converting between AMR- and PCM-coded voice). The MGW 1048 alsocommunicates with other IP multimedia networks 1054.

Push to Talk over Cellular (PoC) capable mobile phones register with thewireless network when the phones are in a predefined area (e.g., jobsite, etc.). When the mobile phones leave the area, they register withthe network in their new location as being outside the predefined area.This registration, however, does not indicate the actual physicallocation of the mobile phones outside the pre-defined area.

FIG. 25 illustrates a PLMN block diagram view of an exemplaryarchitecture in which the geogaming may be incorporated. Mobile Station(MS) 1101 is the physical equipment used by the PLMN subscriber. In oneillustrative embodiment, WT 200 and/or communications device 120 mayserve as Mobile Station 1101. Mobile Station 1101 may be one of, but notlimited to, a cellular telephone, a cellular telephone in combinationwith another electronic device or any other wireless mobilecommunication device.

Mobile Station 1101 may communicate wirelessly with Base Station System(BSS) 1110. BSS 1110 contains a Base Station Controller (BSC) 1111 and aBase Transceiver Station (BTS) 1112. BSS 1110 may include a single BSC1111/BTS 1112 pair (Base Station) or a system of BSC/BTS pairs which arepart of a larger network. BSS 1110 is responsible for communicating withMobile Station 1101 and may support one or more cells. BSS 1110 isresponsible for handling cellular traffic and signaling between MobileStation 1101 and Core Network 1140. Typically, BSS 1110 performsfunctions that include, but are not limited to, digital conversion ofspeech channels, allocation of channels to mobile devices, paging, andtransmission/reception of cellular signals.

Additionally, Mobile Station 1101 may communicate wirelessly with RadioNetwork System (RNS) 1120. RNS 1120 contains a Radio Network Controller(RNC) 1121 and one or more Node(s) B 1122. RNS 1120 may support one ormore cells. RNS 1120 may also include one or more RNC 1121/Node B 1122pairs or alternatively a single RNC 1121 may manage multiple Nodes B1122. RNS 1120 is responsible for communicating with Mobile Station 1101in its geographically defined area. RNC 1121 is responsible forcontrolling the Node(s) B 1122 that are connected to it and is a controlelement in a UMTS radio access network. RNC 1121 performs functions suchas, but not limited to, load control, packet scheduling, handovercontrol, security functions, as well as controlling Mobile Station1101's access to the Core Network (CN) 1140.

The evolved UMTS Terrestrial Radio Access Network (E-UTRAN) 1130 is aradio access network that provides wireless data communications forMobile Station 1101 and User Equipment 1102. E-UTRAN 1130 provideshigher data rates than traditional UMTS. It is part of the Long TermEvolution (LTE) upgrade for mobile networks and later releases meet therequirements of the International Mobile Telecommunications (IMT)Advanced and are commonly known as a 4G networks. E-UTRAN 1130 mayinclude of series of logical network components such as E-UTRAN Node B(eNB) 1131 and E-UTRAN Node B (eNB) 1132. E-UTRAN 1130 may contain oneor more eNBs. User Equipment 1102 may be any user device capable ofconnecting to E-UTRAN 1130 including, but not limited to, a personalcomputer, laptop, mobile device, wireless router, or other devicecapable of wireless connectivity to E-UTRAN 1130. The improvedperformance of the E-UTRAN 1130 relative to a typical UMTS networkallows for increased bandwidth, spectral efficiency, and functionalityincluding, but not limited to, voice, high-speed applications, largedata transfer and IPTV, while still allowing for full mobility.

An exemplary embodiment of a mobile data and communication service thatmay be implemented in the PLMN architecture described in FIG. 25 is theEnhanced Data rates for GSM Evolution (EDGE). EDGE is an enhancement forGPRS networks that implements an improved signal modulation scheme knownas 8-PSK (Phase Shift Keying). By increasing network utilization, EDGEmay achieve up to three times faster data rates as compared to a typicalGPRS network. EDGE may be implemented on any GSM network capable ofhosting a GPRS network, making it an ideal upgrade over GPRS since itmay provide increased functionality of existing network resources.Evolved EDGE networks are becoming standardized in later releases of theradio telecommunication standards, which provide for even greaterefficiency and peak data rates of up to 1 Mbit/s, while still allowingimplementation on existing GPRS-capable network infrastructure.

Typically Mobile Station 1101 may communicate with any or all of BSS1110, RNS 1120, or E-UTRAN 1130. In a illustrative system, each of BSS1110, RNS 1120, and E-UTRAN 1130 may provide Mobile Station 1101 withaccess to Core Network 1140. The Core Network 1140 may include of aseries of devices that route data and communications between end users.Core Network 1140 may provide network service functions to users in theCircuit Switched (CS) domain, the Packet Switched (PS) domain or both.The CS domain refers to connections in which dedicated network resourcesare allocated at the time of connection establishment and then releasedwhen the connection is terminated. The PS domain refers tocommunications and data transfers that make use of autonomous groupingsof bits called packets. Each packet may be routed, manipulated,processed or handled independently of all other packets in the PS domainand does not require dedicated network resources.

The Circuit Switched—Media Gateway Function (CS-MGW) 1141 is part ofCore Network 1140, and interacts with Visitor Location Register (VLR)and Mobile-Services Switching Center (MSC) Server 1160 and Gateway MSCServer 1161 in order to facilitate Core Network 1140 resource control inthe CS domain. Functions of CS-MGW 1141 include, but are not limited to,media conversion, bearer control, payload processing and other mobilenetwork processing such as handover or anchoring. CS-MGW 1140 mayreceive connections to Mobile Station 1101 through BSS 1110, RNS 1120 orboth.

Serving GPRS Support Node (SGSN) 1142 stores subscriber data regardingMobile Station 1101 in order to facilitate network functionality. SGSN1142 may store subscription information such as, but not limited to, theInternational Mobile Subscriber Identity (IMSI), temporary identities,or Packet Data Protocol (PDP) addresses. SGSN 1142 may also storelocation information such as, but not limited to, the Gateway GPRSSupport Node (GGSN) 1144 address for each GGSN where an active PDPexists. GGSN 1144 may implement a location register function to storesubscriber data it receives from SGSN 1142 such as subscription orlocation information.

Serving Gateway (S-GW) 1143 is an interface which provides connectivitybetween E-UTRAN 1130 and Core Network 1140. Functions of S-GW 1143include, but are not limited to, packet routing, packet forwarding,transport level packet processing, event reporting to Policy andCharging Rules Function (PCRF) 1150, and mobility anchoring forinter-network mobility. PCRF 1150 uses information gathered from S-GW1143, as well as other sources, to make applicable policy and chargingdecisions related to data flows, network resources and other networkadministration functions. Packet Data Network Gateway (PDN-GW) 1145 mayprovide user-to-services connectivity functionality including, but notlimited to, network-wide mobility anchoring, bearer session anchoringand control, and IP address allocation for PS domain connections.

Home Subscriber Server (HSS) 1163 is a database for user information,and stores subscription data regarding Mobile Station 1101 or UserEquipment 1102 for handling calls or data sessions. Networks may containone HSS 1163 or more if additional resources are required. Exemplarydata stored by HSS 1163 include, but is not limited to, useridentification, numbering and addressing information, securityinformation, or location information. HSS 1163 may also provide call orsession establishment procedures in both the PS and CS domains.

The VLR/MSC Server 1160 provides user location functionality. WhenMobile Station 1101 enters a new network location, it begins aregistration procedure. A MSC Server for that location transfers thelocation information to the VLR for the area. A VLR and MSC Server maybe located in the same computing environment, as is shown by VLR/MSCServer 1160, or alternatively may be located in separate computingenvironments. A VLR may contain, but is not limited to, user informationsuch as the IMSI, the Temporary Mobile Station Identity (TMSI), theLocal Mobile Station Identity (LMSI), the last known location of themobile station, or the SGSN where the mobile station was previouslyregistered. The MSC server may contain information such as, but notlimited to, procedures for Mobile Station 1101 registration orprocedures for handover of Mobile Station 1101 to a different section ofthe Core Network 1140. GMSC Server 1161 may serve as a connection toalternate GMSC Servers for other mobile stations in larger networks.

Equipment Identity Register (EIR) 1162 is a logical element which maystore the International Mobile Equipment Identities (IMEI) for MobileStation 1101. In a typical embodiment, user equipment may be classifiedas either “white listed” or “black listed” depending on its status inthe network. In one embodiment, if Mobile Station 1101 is stolen and putto use by an unauthorized user, it may be registered as “black listed”in EIR 1162, preventing its use on the network. Mobility ManagementEntity (MME) 1164 is a control node which may track Mobile Station 1101or User Equipment 1102 if the devices are idle. Additional functionalitymay include the ability of MME 1164 to contact an idle Mobile Station1101 or User Equipment 1102 if retransmission of a previous session isrequired.

While example embodiments of geogaming have been described in connectionwith various computing devices/processors, the underlying concepts canbe applied to any computing device, processor, or system capable ofimplementing geogames. The various techniques described herein can beimplemented in connection with hardware or software or, whereappropriate, with a combination of both. Thus, the methods andapparatuses of geogaming can be implemented, or certain aspects orportions thereof, can take the form of program code (i.e., instructions)embodied in tangible storage media having a tangible physical structure.Examples of tangible storage media include floppy diskettes, CD-ROMs,DVDs, hard drives, or any other tangible machine-readable storage medium(tangible computer-readable storage medium). Thus, a tangible storagemedium as described herein is not intended to be a transient propagatingsignal. When the program code is loaded into and executed by a machine,such as a computer, the machine becomes an apparatus for implementinggeogames. In the case of program code execution on programmablecomputers, the computing device will generally include a processor, astorage medium readable by the processor (including volatile andnon-volatile memory and/or storage elements), at least one input device,and at least one output device. The program(s) can be implemented inassembly or machine language, if desired. The language can be a compiledor interpreted language, and combined with hardware implementations. Asevident from the herein description, a tangible storage medium is to beconstrued to be statutory subject matter under United States Code, Title35, Section 101 (35 U.S.C. §101).

The methods and apparatuses for geogaming also can be practiced viacommunications embodied in the form of program code that is transmittedover some transmission medium, such as over electrical wiring orcabling, through fiber optics, or via any other form of transmission,wherein, when the program code is received and loaded into and executedby a machine, such as an EPROM, a gate array, a programmable logicdevice (PLD), a client computer, or the like, the machine becomes anapparatus for implementing geogames. When implemented on ageneral-purpose processor, the program code combines with the processorto provide a unique apparatus that operates to invoke the functionalityof geogaming.

While geogaming has been described in connection with the variousembodiments of the various figures, it is to be understood that othersimilar embodiments can be used or modifications and additions can bemade to the described embodiments for geographic based logical messageaddressing and delivery without deviating therefrom. For example, oneskilled in the art will recognize that geogaming as described in thepresent application may apply to any environment, whether wired orwireless, and may be applied to any number of such devices connected viaa communications network and interacting across the network. Therefore,geogaming should not be limited to any single embodiment, but rathershould be construed in breadth and scope in accordance with the appendedclaims.

1. A wireless device comprising: a processor portion configured to:determine a boundary of each virtual object in a geogame based on areceived event information; determine a current location of the device;determine if the current location of the device intersects a boundary ofa virtual object; an input/output portion configured to: geocast anindication of an event; and receive respective geocasts from otherdevices participating in the geogame; and a user interface portionconfigured to: render a representation of at least one virtual object inthe geogame based on the received event information.
 2. The device ofclaim 1, wherein: if it is determined that the current location of thedevice intersects a boundary of a virtual object, determine a type ofvirtual object whose boundary the device intersects, wherein the type isone of a first type, a second type, or a third type; the processorportion further is configured to: if the type is determined to be afirst type: determine that the virtual object whose boundary the deviceintersects is a captured virtual object; and reward a player utilizingthe device to capture the virtual object; if the type is determined tobe a second type, penalize the player utilizing the device whoseboundary intersects the boundary of the virtual object; and if the typeis determined to be a third type: determine if the device whose currentlocation intersects with the boundary of the virtual object haspreviously intersected a boundary of the virtual object; and if theboundary of the device whose current location intersects with theboundary of the virtual object has not previously intersected a boundaryof the virtual object, penalize the player utilizing the device toparticipate in the geogame; the input/output portion further isconfigured to: geocast an indication that a player is rewarded; andgeocast an indication that a player is penalized; and the user interfaceportion further configured to: render an indication that a player isrewarded; and render an indication that a player is penalized.
 3. Thedevice of claim 2, wherein the processor portion is configured to removea captured virtual object from geogame play.
 4. The device of claim 2,wherein the processor portion is configured to convert a capturedvirtual object to the third type virtual object that moves toward acurrent location of a device participating in the geogame other than acurrent location of the device whose boundary intersected with theboundary of the virtual object.
 5. The device of claim 1, wherein atleast one virtual object is stationary.
 6. The device of claim 1,wherein at least one virtual object moves in a predetermined pattern. 7.The device of claim 1, wherein at least one virtual object moves in anon-predetermined pattern.
 8. The device of claim 1, wherein at leastone virtual object moves toward a location of the device.
 9. The deviceof claim 1, wherein at least one virtual object moves away from alocation of the device.
 10. A method of playing a geogame, the methodcomprising: determining a boundary of each virtual object in a geogamebased on a received event information; determining a current location ofthe device; geocasting an indication of the current location of thedevice; determining if the current location of the device intersectswith a boundary of a virtual object; and rendering a representation ofat least one virtual object in the geogame based on the received eventinformation.
 11. The method of claim 10, further comprising: if it isdetermined that the current location of the device intersects with aboundary of a virtual object, determining a type of virtual object whoseboundary the device intersects, wherein the type is one of a first type,a second type, or a third type; if the type is determined to be a firsttype: determining that the virtual object whose boundary the deviceintersects is a captured virtual object; rewarding a player utilizingthe device to capture the virtual object; and geocasting an indicationthat the player is rewarded; and if the type is determined to be a thirdtype: determining if the device whose current location intersects withthe boundary of the virtual object has previously intersected a boundaryof the virtual object; if the boundary of the device whose currentlocation intersects with the boundary of the virtual object has notpreviously intersected a boundary of the virtual object, penalizing theplayer utilizing the device to participate in the geogame; andgeocasting an indication that a player is penalized.
 12. The method ofclaim 11, wherein a captured virtual object is removed from geogameplay.
 13. The method of claim 11, wherein a captured virtual object isconverted to the third type virtual object that moves toward a currentlocation of a device participating in the geogame other than a currentlocation of the device whose boundary intersected with the boundary ofthe virtual object.
 14. The method of claim 10, wherein at least onevirtual object is stationary.
 15. The device of claim 10, wherein atleast one virtual object moves in a predetermined pattern.
 16. Thedevice of claim 10, wherein at least one virtual object moves in anon-predetermined pattern.
 17. The device of claim 10, wherein at leastone virtual object moves toward a location of the device.
 18. The methodof claim 11, wherein at least one virtual object moves away from alocation of the device.
 19. A computer readable storage mediumcomprising computer executable instructions for causing a processor toperform the steps of: determining a boundary of each virtual object in ageogame based on a received indication of location of each virtualobject; determining a current location of the device; geocasting anindication of the current location of the device; determining if thecurrent location of the device intersects with a boundary of a virtualobject; if it is determined that the current location of the deviceintersects with a boundary of a virtual object, determining a type ofvirtual object whose boundary the device intersects, wherein the type isone of a first type, a second type, or a third type; rendering arepresentation of a each virtual object in the geogame based on thereceived indication of a location of each virtual object in the geogame;rendering a representation of the current location of the device; andrendering a representation of a current location of each other deviceparticipating in the geogame based on the received geocasts from otherdevices participating in the geogame.
 20. The medium of claim 19, theinstructions further for causing the processor to: if the type isdetermined to be a first type: determine that the virtual object whoseboundary the device intersects is a captured virtual object; reward aplayer utilizing the device to capture the virtual object; andgeocasting an indication that the player is rewarded; and if the type isdetermined to be a third type: determine if the device whose currentlocation intersects with the boundary of the virtual object haspreviously intersected a boundary of the virtual object; if the boundaryof the device whose current location intersects with the boundary of thevirtual object has not previously intersected a boundary of the virtualobject, penalize the player utilizing the device to participate in thegeogame; and geocast an indication that a player is penalized.